home *** CD-ROM | disk | FTP | other *** search
/ Cream of the Crop 22 / Cream of the Crop 22.iso / program / tdk_v120.zip / DOORKIT.DOC < prev    next >
Text File  |  1996-07-23  |  16KB  |  271 lines
  1. ───────────────────────────────────────────────────────────────────────────────
  2.    ▀▀▀▀▀▀▀▀  ▀▀▀▀▀▀    ▀▀   ▀▀
  3.      ▀▀     ▀▀   ▀▀   ▀▀  ▀▀
  4.     ▀▀     ▀▀   ▀▀▀  ▀▀▀▀▀  The DoorKit!
  5.    ▀▀     ▀▀   ▀▀   ▀▀  ▀▀
  6.   ▀▀     ▀▀▀▀▀▀    ▀▀    ▀▀
  7.   The BBS Door Development Kit By The People - For The People!
  8. ───────────────────────────────────────────────────────────────────────────────
  9.   The ANSI/ASCII/RIP/MAX DoorKit v1.20
  10.   No Copyright Notices Expressed Or Implied
  11.   Compiled By Larry L. Athey From Numerous Sources
  12. ───────────────────────────────────────────────────────────────────────────────
  13.  
  14.   NOTE: The DoorKit! requires you to have Turbo Pascal 7.0 or Borland Pascal
  15.         7.0 With Objects. Certain compiler directives in these units are not
  16.         campatible with Turbo Pascal 6.0....If you have Turbo Pascal 6.0 you
  17.         will have to make a number of modifications to this kit.  Sorry, but
  18.         since I don't use TP6.0, I cannot assist you with any modifications.
  19.  
  20.  
  21.   Welcome to The DoorKit!
  22.   ───────────────────────
  23.   This is a compilation of various procedures and functions by various authors
  24.   structured in such a way that I believe makes one of the most powerful BBS
  25.   door development kits available. The reason for me making this kit is because
  26.   out of all the door development kits out there I've tried (with source code)
  27.   they all fall short in one way or another. So what I have done is take all
  28.   of the the best features of numerous door kits, various source code samples
  29.   from SWAG, plus procedures I have written myself, and compiled one big door
  30.   development kit.
  31.  
  32.   If you are concerned with the legality of the methods used to develop this
  33.   kit, let's just say (for the sake of legal matters) that this kit is really
  34.   a "Parody" on other people's kits. Really, it's a parody.....I just have a
  35.   crappy sense of humor when it comes to programming. Parodies are legal and
  36.   cannot go hand in hand with plagiarism. Just ask Weird Al Yankovich....  :)
  37.   If you are still concerned at this point, just look at it like this: Every
  38.   major door development kit out there does the same thing, the difference is
  39.   I'm admitting to the use of other people's code whereas they are not. Still
  40.   the code used in this kit has been completely modified to make it work hand
  41.   in hand with the rest of the kit, so none of these derivitives are any way
  42.   comparable to their original sources.
  43.  
  44.   I am by no means taking credit for this kit, all of the authors of the door
  45.   kits and SWAG contributors did all of the real work. All I did is make some
  46.   modifications, debugging, and repackage the procedures and functions in here.
  47.   Make note that all of these kits that I used parts from plainly state that
  48.   I cannot make another kit using their source that I intend to sell. This is
  49.   why there is no price tag on this kit. These people donated their source to
  50.   the public and I am doing the same thing with my source as well.
  51.  
  52.   By no means am I trying to tell you that this is The Best door kit in the
  53.   world. I am sure that you can find others out there that will run circles
  54.   around this one. The only reason I am plugging this kit is because this is
  55.   the one that I use in my doors and I get literally TONS of compliments on
  56.   my doors. One thing you will probably not like about this kit is that the
  57.   constants and variables used in it take up about 9.5K of your data segment.
  58.   I know, I could have made it take up much less, but the only way I could do
  59.   that is to use pointers. Unfortunately, there are a lot of programmers out
  60.   there that think pointers are the work of Satan himself. So in the spirit
  61.   lazy programming techniques, you will lose 9.5K of your data segment with
  62.   this kit. However, you can modify this at your own discretion so that the
  63.   kit won't eat up as much memory. To tell you the truth, other door kits I
  64.   have tried eat up about the same amount or more.
  65.  
  66.   Another thing you may notice is that there is no support for the door game
  67.   L.O.R.D. and no other Inter-BBS games. I don't play door games and neither
  68.   do the users on my BBS. If the opposite was true, then I would know about
  69.   this kind of stuff. As it stands, I don't know squat about it so there is
  70.   no way I can support it. But still, since this kit contains full source
  71.   code, you are free to add it. If you do, please send me all of the source
  72.   and other information needed so I can update The DoorKit archive.
  73.  
  74.   Do with this kit what you will....All I ask is if you find a better way of
  75.   doing something (which you will), please send me a copy of what you did so
  76.   that I can update future versions of this kit. Plus it will help me learn
  77.   more about the way other people work. My code bores me, I like looking at
  78.   other people's code to learn new tricks. I will also add your name to the
  79.   list shown below so you are given full credit for your work.
  80.  
  81. ───────────────────────────────────────────────────────────────────────────────
  82.  
  83.   Basic Features:
  84.   ───────────────
  85.   -Autodetects the caller's graphics rather than relying on drop file info.
  86.   -Supports ANSI/AVATAR/TTY/RIP/MAX graphics (See MAXINFO.DOC).
  87.   -Supports DOOR.SYS and DORINFOx.DEF drop files.
  88.   -Full error trapping and logging of expected & unexpected errors.
  89.   -Full monitoring of carrier dropping and user inactivity time-outs.
  90.   -Uses a "Virtual Screen" for all local screen drawing.
  91.   -DOS, Double-Dos, DesqView, Windows, OS/2, and Novell Netware friendly.
  92.   -Built in highly optimized Pascal 'EXEC' replacement.
  93.   -Only leaves a 1.2K footprint in memory when swapped out.
  94.   -Automatic swapping to EMS -> XMS -> Disk.
  95.   -Supports Fossil and UART communications routines.
  96.   -Full support for non-standard port and IRQ settings.
  97.   -All door serial I/O settings are fully configurable.
  98.   -Program startup/initialization streamlined into one InitDoorKit command.
  99.   -Automatic handling of all program exit processes.
  100.   -Uses typed control files rather than text based INI files.
  101.   -Includes a freeware control file editor to distribute with your doors.
  102.   -Easily definable sysop "F-Keys", no Far Calls needed for these functions.
  103.   -Easily definable command line parameters.
  104.   -Full support for local and remote Cursor, Home, End, and Delete keys.
  105.   -Built in split screen and line by line chat modes.
  106.   -Numerous cosmetic procedures already written into the package.
  107.   -Numerous string handling procedures already written into the package.
  108.   -Numerous file handling procedures already written into the package.
  109.   -Built in questionnaire/script language.
  110.   -Built in online text file reader procedure.
  111.   -Supports inline color tokens for coloring text files.
  112.   -Library of global system variable tokens for use in screen/text files.
  113.   -Includes procedures for full activity and error logging.
  114.  
  115. ───────────────────────────────────────────────────────────────────────────────
  116.  
  117.   Technical Information:
  118.   ──────────────────────
  119.   Sorry, this isn't going to be very extensive. The units included in this
  120.   package are commented pretty well, so there won't be a whole hell of a lot
  121.   documentation. Sorry about that, but if somebody else out there wants to
  122.   write complete documentation for it.....Have at it! I'm sure others will
  123.   probably thank you for it.....I really don't see the lack of documentation
  124.   being a problem since there has been this world-wide campaign initiated to
  125.   abolish the reading of documentation. All you techno-jocks will just have
  126.   to "Make-Due" with the code comments.....  ;)  If you don't bother to read
  127.   the comments in each unit, then you are not going to know about all of the
  128.   possibilities you have at hand. So please....READ!
  129.  
  130.  
  131.   Door Initialization:
  132.   ────────────────────
  133.   The DoorKit uses binary, or "Typed" files for storing the configuration for
  134.   each node. The naming convention for these "Control Files" is NODE###.CTL
  135.   with the ### representing the current node number. I have included a little
  136.   utility for creating/editing these control files. You may package this in
  137.   your doors, or you may write your own configuration routines to handle it.
  138.  
  139.   The program MAKECTL.EXE is the control file editor. You simply execute it
  140.   with the node number on the command line to tell the program which node you
  141.   wish to create or edit the control file for. You may also wish to write a
  142.   procedure to read text based control files. I don't like text files because
  143.   they just slow down a program. A typed file is just a one shot open, read,
  144.   and close. Whereas text files always require you to read a line, translate
  145.   it into data the door can use, and repeat the process until you have all of
  146.   your critical variables set. (Can we say: Sloooooowwwww?)
  147.  
  148.  
  149.   ANSI Screen Files:
  150.   ──────────────────
  151.   I'll say it right now, you may find a better way to handle ANSI screen files
  152.   than I have. With the current design, you must save your ANSI screen files
  153.   with a maximum of 128 characters per line. I don't know how other drawing
  154.   programs work, but with "TheDraw" you are prompted to enter the max width of
  155.   the screen file before you save it. Simply set this to 128 characters and
  156.   procedure with the saving process. The reason this kit requires screens to
  157.   be saved like this is because of the way screens are translated. Each line
  158.   of the screen file is read and then checked for global system variables and
  159.   translated if they are found. Well, don't ask me why, but something somehow
  160.   gets lost in the translation. Saving the screens 128 characters wide fixes
  161.   the problem for some reason. If you can find a way around it, please let me
  162.   know how you did it....You may also want to note that ANSI screen files use
  163.   direct video writing rather than BIOS writes. This results in a much faster
  164.   displaying of screens on the local side. (See ANSIUNIT.PAS)
  165.  
  166.  
  167.   Shutting Down Your Door:
  168.   ────────────────────────
  169.   There is no need to call any special procedure to shut down The DoorKit at
  170.   the end of your program. If you look at the _EXIT.PAS unit, you will notice
  171.   that there is automatic error handling in this kit. Even if your door exits
  172.   with a runtime error, all of the required exit processes will be taken care
  173.   of for you. You can add steps to the exit process with AddToExitChain. Just
  174.   read the comments in the _EXIT.PAS unit and you'll see how simplified the
  175.   exit or shutdown process is. What's more is if your program bails out with
  176.   a runtime error, a detailed description of the error is written to an error
  177.   log file. Believe me, this _EXIT.PAS is a lifesaver of a unit!
  178.  
  179. ───────────────────────────────────────────────────────────────────────────────
  180.  
  181.   Credits:
  182.   ────────
  183.  
  184.   Bob Dalton      - The DDPLUS development library. A very nice kit and the
  185.                     first one I ever used, unfortunately the author(s) didn't
  186.                     plan ahead with the kit. If you wanted to write any kind
  187.                     of a program where you wanted to control the cursor with
  188.                     your arrow keys you were screwed. You would almost have
  189.                     to completely rewrite the DDPLUS.PAS unit to do it. This
  190.                     is still a really nice and well documented kit, it's just
  191.                     kinda limited in its native design.
  192.  
  193.   John Stephenson - The JSDoor development library. I would say that 40% of
  194.                     this kit was created using portions of the JSDoor kit. I
  195.                     would have just stayed with JSDoor, but there were just
  196.                     too many bugs in it. With the way that JSDoor is designed
  197.                     it makes it almost impossible to track down problems in
  198.                     it unless you were the one that wrote it. There are some
  199.                     serious problems in it's time keeping method and the way
  200.                     it handles sysop keys. The split screen chat is screwed
  201.                     up too, but since it's too "Spaghetti-ish" it's just too
  202.                     wierd to fix. Too bad....
  203.  
  204.   Jason Morriss   - The COMMIO development library. COMMIO is (as this kit is)
  205.                     a compilation of other people's source as well as his own.
  206.                     I noticed his serial communications routines came from the
  207.                     DDPLUS door development kit which are the same ones as I
  208.                     used in here. However, these units have been modified in
  209.                     a big way. As with JSDoor, this is another one of those
  210.                     kits that has a lot of bugs in it and since its structure
  211.                     was so weird, it was simply too difficult to fix it....
  212.  
  213.   SWAG Support    - The SourceWare Archival Group. A HUGE amount of code in
  214.                     this kit came from SWAG. Since there are too many people
  215.                     to name, I will simply pay credit to "SWAG" here.
  216.  
  217.   Thomas Wagner   - The EXEC.PAS unit and supporting files. This is a great
  218.                     unit specifically designed to replace the EXEC command in
  219.                     Pascal. The unit has built in memory swapping and when
  220.                     you execute a child process or drop to DOS, only a 1.2K
  221.                     foot print is left in memory thus giving the most free
  222.                     memory to run external programs.
  223.  
  224.   Dorinda D Hayek - Major contribution to the MAX Graphics development kit
  225.                     and made a number of changes in TDK v1.10 to optimize
  226.                     performance and enhance features. Her contribution to
  227.                     TDK v1.10 made the quick release of v1.20 possible.
  228.  
  229.   Larry L. Athey  - The structure of TDK, ANSIUNIT.PAS unit, numerous complex
  230.                     procedures, numerous "Artsy/Fartsy" procedures, and the
  231.                     concept of the MAX graphics protocol and development kit.
  232.  
  233.   Anybody Else?   - If there is a chance that I'm using code in this kit from
  234.                     anybody I neglected to mention, sorry about that. Let me
  235.                     know and tell me what portion of the code it is that you
  236.                     are the author of and I'll add your name to the list.
  237.  
  238. ───────────────────────────────────────────────────────────────────────────────
  239.  
  240.   But What About MAX?
  241.   ───────────────────
  242.   The MAX Graphics haven't been implemented yet. I'm waiting to make sure The
  243.   DoorKit will work fine on its own as an ANSI/ASCII/RIP kit first. After I
  244.   am positive that everything is solid, then the MAX Graphics will be added.
  245.   I am still testing MAXterm on my system and I am happy to say that all is
  246.   well. It's just a matter of finishing up the script language and animation
  247.   commands for the door interface. For more information on MAX Graphics, see
  248.   the file MAXINFO.DOC.....
  249.  
  250. ───────────────────────────────────────────────────────────────────────────────
  251.  
  252.   What's New?
  253.   ───────────
  254.   Arrrggghhh....Man, there are way too many things to list and I honestly
  255.   couldn't tell you anyway. All I can say is that a real sharp programmer
  256.   in Longmont, Colorado got ahold of TDK and enhanced the hell out of it!
  257.   Major thanks to Dorinda D. Hayek, she's one hell of a programmer!
  258.  
  259. ───────────────────────────────────────────────────────────────────────────────
  260.  
  261.   Larry L. Athey
  262.   1239 Cheyenne
  263.   Alliance, NE, 69301
  264.   Owner    : BBS Utiliteez Software
  265.   FAX/BBS #: (308)762-2239
  266.   FidoNet  : 1:285/703
  267.   GDS-Net  : 100:1010/1
  268.   ivNET    : 411:1500/0
  269.   Internet : larry.athey@tos.daphnis.com, larry.athey%otherside@ivsoft.com
  270.  
  271.